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Description 

SYSTEM AND METHOD FOR 
AUTHORIZING THIRD-PARTY 
TRANSACTIONS FOR AN ACCOUNT AT A 
FINANCIAL INSTITUTION ON BEHALF OF 
THE ACCOUNT HOLDER 

Background of Invention 

[0001] Automatic drafts or debits, and direct deposits are elec- 
tronic alternatives to the traditional, consumer and busi- 
ness banking processes of writing checks and making de- 
posits using paper forms. These automated alternatives 
are well understood and have existed for many years. In 
the case of drafts or debits, an account-holder customer 
of a bank or similar financial institution contacts the biller 
to arrange the debits or drafts. In the case of debits to a 
bank account, the account holder provides the biller with 
routing and transit information for his or her bank ac- 
count, or a copy of a voided check. The biller is typically a 



third party (that is, not the account holder or the bank) to 
whom the account holder makes regular payments, such 
as for an electric bill, a magazine subscription, a mort- 
gage payment, etc. Once the biller has received the ac- 
count-holder's authorization to deduct payments from the 
account- holder's account including the bank account in- 
formation, the biller automatically debits the account- 
holder's account as bills become due. These debits are of- 
ten made through the Automated Clearing House (ACH) 
Network. The ACH Network is a highly reliable and effi- 
cient nationwide, batch-oriented electronic funds transfer 
system for interbank clearing of electronic payments. The 
ACH Network is operated by a conglomeration of entities, 
including the U.S. Federal Reserve. It is well known and 
will not be discussed in additional detail. Many third -party 
billers will also arrange automatic debits to a card product 
such as credit or debit card account, in which case, one of 
the many card networks is used to process the payment. 
[0002] Direct deposits are typically made to a bank account, or 
banking type of account at a financial institution, how- 
ever, credits applied to a credit account are analogous to 
direct deposits. In most cases, account holders will ar- 
range a direct deposit for salary received from an em- 



plover, although other types of payments, such as insur- 
ance payments, or government payments can also be re- 
ceived by direct deposit. In any case, to arrange a direct 
deposit, the account holder contacts the third-party direct 
depositor and provides the appropriate account informa- 
tion, just as in the case of automatic drafts. The direct de- 
positor then automatically and electronically transfers the 
appropriate amount of money into the account-holder's 
account when payment is due. Direct deposits, like auto- 
matic drafts, often make use of the ACH Network. 
[0003] Historically, banking customers have arranged both auto- 
matic drafts and direct deposits through the use of paper 
forms. Recently, some business entities have provided 
electronic means to arrange these transactions, typically 
via a secure Web site, or some secure personal computer 
software application. However, even when automatic 
drafts and/or direct deposits are arranged using elec- 
tronic means, the arranging of at least some of these 
transactions involves the account holder contacting each 
responsible third party directly in some way. Thus, at least 
some changes to these transactions, for example, a 
change as to which specific bank or other account a 
transaction is to be applied, involves the account holder 



again contacting the responsible third-party biller or di- 
rect depositor to arrange the change. A consumer or busi- 
ness that makes extensive use of automatic drafts and di- 
rect deposits by multiple third parties can find the task of 
making such a change daunting, since it requires multiple 
billers and/or direct depositors to be notified. Thus, the 
size of this task effectively deters some consumers and 
businesses from moving an account to a new financial in- 
stitution, or even changing which account is used for such 

transactions within a financial institution. 
Summary of Invention 

[0004] The present invention, by way of example embodiments 
herein presented, provides for a method and system 
whereby a financial institution can collect, process, trans- 
mit and confirm authorizations to third parties for elec- 
tronic payments and direct deposits on behalf of its ac- 
count-holder customer. Through access to centralized 
authorizations through the financial institution, a cus- 
tomer can be relieved of much of the repetitive burden of 
contacting various third parties to arrange for or make 
changes to automatic draft payments and direct deposits. 
Such relief can be especially beneficial when a customer 
who makes extensive use of automatic payments and/or 



direct deposits changes financial institutions, or changes 
accounts within the same financial institution, as may be 
required if the security of the old account has been com- 
promised. The benefits of the invention, however, are not 
limited to these situations. 
[0005] | n a t least some embodiments of the invention, a method 
of processing account-holder requests to authorize third- 
party transactions for an account includes the establish- 
ment of a pre-existing list of prospective third-party par- 
ticipants. These third-party participants can be direct de- 
positors such as employers, and billers such as utility 
companies. The financial institution receives account- 
holder requests to authorize third-party transactions. 
Specific requests from among the account-holder re- 
quests are matched to third-party participants. At least 
one request is forwarded to at least one participant, but 
multiple requests can be forwarded to a given participant, 
either from one account holder or from multiple account 
holders at the financial institution. A request for an auto- 
mated transaction is forwarded to the third-party partici- 
pant on behalf of the account holder, so that the account 
holder does not have to contact the participant entity di- 
rectly. In at least some embodiments, the financial institu- 



tion receives a participant confirmation from each specific 
third-party participant, and forwards an account-holder 
confirmation to the account holder. 

[0006] information on third-party participants and account- 
holder customers can be stored in data repositories at the 
financial institution. This information can include partici- 
pant profiles or account-holder profiles as the case may 
be. These profiles can include communication preferences 
for the relevant parties. Communication preferences can 
include, for example, whether a participant or an account 
holder prefers electronic communication or paper com- 
munication with the financial institution. Specifics can be 
provided, such as whether the Internet or some other 
form of electronic communication is used to handle com- 
munication with a third-party participant. Additionally, 
data on past and pending account-holder requests, con- 
firmations and other events can be maintained. 

[0007] | n some embodiments, the system of the invention can in- 
clude various engines and data repositories that work to- 
gether to provide the means for implementing embodi- 
ments of the invention. Some of these can be imple- 
mented manually or using paper-based means. Even in 
embodiments where all of the engines and data reposito- 



ries are computerized, the creation and use of paper 
records as part of the processes disclosed can be sup- 
ported. 

[0008] For example, a system according to some embodiments 
includes a user interface to receive account-holder re- 
quests to authorize the third-party transactions. This user 
interface can make use of the Internet, such as by a se- 
cure Web site. At least one engine can be operatively con- 
nected to the user interface to perform sorting, parsing, 
and matching as needed to handle the requests. A third- 
party participant interface can be provided to forward the 
specific requests to the specific third-party participants. 
In some embodiments, the financial institution will have 
an established relationship with the third-party partici- 
pants, and interactive, electronic communications be- 
tween the participant and the financial institution can be 
supported. At least one data repository is connected 
within the system, and can include third-party participant 
profiles, as well as account-holder information and any 
other data that needs to be maintained. In some embodi- 
ments, a fulfillment system provides account-holder con- 
firmation of specific requests. The fulfillment system can 
provide these communications according to stored ac- 



count-holder preferences, which may include electronic or 
paper-based communications. 
[0009] | n some embodiments, the invention is, at least in part 
implemented via a computing platform or a collection of 
computing platforms interconnected by one or more net- 
works, such as the Internet, a corporate intranet, and/or 
some other form of electronic communication. A com- 
puter program product or products containing computer 
programs with various instructions can be used to cause 
the hardware to carry out, at least in part, the methods of 
the invention. Software engines can be operated on 
servers or workstations. Data repositories are operatively 
connected to the engines. Such data repositories can re- 
side on the same platform as some or all of the various 
software engines or they can reside on a database server 

connected over a network. 
Brief Description of Drawings 

[0010] FIG. 1 is a flowchart illustrating a method according to 
some embodiments of the invention. 

[0011] FIG. 2 is a system block diagram showing various system 
software engines, data repositories, and other elements 
and how they are interconnected according to some em- 
bodiments of the invention. FIG. 2 is broken into FIG. 2A 



and 2B for clarity. 
[0012] FIG. 3 is a schematic representation of information con- 
tained in a participant profile in a data repository accord- 
ing to at least some example embodiments of the inven- 
tion. 

[0013] FIG. 4 is a network diagram illustrating the hardware and 
network connections involved in implementing an exam- 
ple embodiment of the invention. FIG. 4 is broken into 

FIG. 4A and 4B for clarity. 
Detailed Description 

[0014] The present invention will now be described in terms of 
specific, example embodiments. It is to be understood 
that the invention is not limited to the example embodi- 
ments disclosed. It should also be understood that not 
every feature of the methods and systems described is 
necessary to implement the invention as claimed in any 
particular one of the appended claims. Various elements 
and features of various embodiments are described to 
fully enable the invention. It should also be understood 
that throughout this disclosure, where a process or 
method is shown or described, the steps or sub- 
processes of the process or method may be performed in 
any order or simultaneously, unless the contrary is clear 



from the context, or is expressly stated. Also, the time 
that elapses between steps can vary. It should also be un- 
derstood that with respect to flowcharts, block diagrams, 
and data structures, not every possible signal flow, data 
path, or structure element is shown. Rather, for clarity, 
only those important to the inventive concepts being dis- 
cussed may be illustrated, although others may be dis- 
cussed in this description. 

[0015] The meaning of certain terms as used generally in the 
context of this disclosure should be understood as fol- 
lows. The term "financial institution" is used herein in its 
broadest sense. Financial institutions that process trans- 
actions of the type discussed can include banks, credit 
unions, stock brokerages, credit card companies, loan 
agencies, and other types of institutions that are not 
strictly banks in the historical sense. The use of the term 
"financial institution" herein is meant to encompass all 
such possibilities. 

[0016] The terms "third party," "third-party participant," "partici- 
pant," and the like are in most cases meant to refer to en- 
tities to which an account holder would pay money upon 
receiving a bill and/or entities that would make direct de- 
posits to an account-holder's account. Third-party partic- 



ipants can be "direct depositors" and/or "billers." The 
term "third party" is used because in the typical case, such 
an entity is yet a third entity after considering the cus- 
tomer account-holder and the financial institution. How- 
ever, the term is meant to encompass the situation where 
the "third party" may be the financial institution itself act- 
ing in another capacity. For example, an account holder 
may process a loan payment to the same bank in which 
the account resides using the methods and systems ac- 
cording to embodiments of the invention. Likewise, auto- 
mated transfers between accounts at a bank can be con- 
sidered automatic drafts or direct deposits, depending on 
the point of view. Any of these types of transactions can 
be considered "third-party transactions." Such transac- 
tions can also include check card transactions and in fact, 
any transaction whereby the authority to perform the 
transaction can be granted to the third party by the ac- 
count holder and thereinafter resides with the third-party 
debitor or depositor. Regardless, as used herein, the term 
"account holder" is meant to refer to a person, entity, 
business, etc. who owns or controls the account at the fi- 
nancial institution to which these transactions apply. An 
account holder can also be referred to as a "customer" of 



the financial institution. 

[0017] The term "user" and related terms such as "user interface" 
as used herein are meant in the broadest sense. An ac- 
count holder or customer of a financial institution can be 
a "user" of a system according to embodiments of the in- 
vention, especially where transaction authorization re- 
quests are submitted from the account-holder's personal 
computer over the Internet. As will be discussed below, a 
"user" can also be an employee of a financial institution 
who inputs or manages information at a branch office for 
a customer. In some cases, a participant may be a user, 
especially if the participant has interactive access to a 
system according to an embodiment of the invention. 

[0018] FIG. 1 shows an example process or method according to 
the invention, in flowchart form. As is typical with 
flowchart illustrations, various sub-processes, elements, 
or steps are represented by process blocks. At block 102 
the financial institution establishes a list of prospective 
third-party participants. This can be done in many ways. 
The financial institution may wish to solicit businesses 
and employers to participate in a commercial service of- 
fering, to the advantage of all parties. Alternatively, the 
list could be comprehensive list established from public 



records, from the financial institution's own records for 
from some other source. The list can be segmented or 
sorted by geography, zip code, types of entities, etc. At 
block 104, the institution receives account-holder request 
data, which includes requests to set-up, transfer, or 
maintain direct debit(s) and/or direct deposit(s). These re- 
quests can be received through an employee user, on be- 
half of the consumer, directly from a business or govern- 
ment account-holder, or directly from a consumer ac- 
count-holder, perhaps via the Internet. An interactive ap- 
plication can be used to gather the request data. Such an 
application can identify the customer, present a list of po- 
tential accounts, and present a list of potential partici- 
pants perhaps based on the customer account-holder's 
zip code. A set-up window can be displayed with informa- 
tion about the third-party participant as well as fields for 
all the data elements for the request that the participant 
has previously identified. Disclosures pertinent to the par- 
ticipant (from a participant profile data repository to be 
discussed in more detail later) can be displayed. A record 
of the request data received can be made in a database or 
data repository for future reference. 
[0019] At block 106 of FIG. 1, the requests are parsed and spe- 



cific requests are matched to specific participants. This 
sorting and routing function is typically performed by a 
server or networked computing platform. At block 108, 
specific requests are forwarded to the appropriate third- 
party participants. This can be done in such a way to ac- 
commodate each participant's specific communication 
preferences. It can be done in real time or in batch mode 
via computer networks, such as the Internet or some other 
form of electronic communication, or even be forwarded 
via a printed request sent through the postal service or a 
courier. Once the requests are forwarded, the financial in- 
stitution waits for confirmation of requests from third- 
party participants. During this time, which in some cases 
may be only fractions of seconds, the participant's sys- 
tems process the request(s). This processing can involve 
updates to a participant's accounts receivable system, ac- 
counts payable system or payroll system to affect the set- 
up, maintenance or transfer of the debit(s) and/or direct 
deposit(s). Such updates can occur in a completely auto- 
mated fashion, or be completely or partially effectuated 
manually, in which case, the wait time for confirmation 
back to the financial institution can be significant. In ei- 
ther case, the waiting is represented by decision block 



110. A specific wait time can be built into the system of 
the invention. If confirmation is not received at block 110 
in this time, a retry process can be initiated and carried 
out at block 112. Decision block 114 represents branch- 
ing dependent on the outcome of retry process 112. If 
there is still no confirmation from a third-party participant 
of an account-holder request, error handling can be un- 
dertaken at block 116. 
[0020] Once confirmation has been received at any of blocks 110, 
114, or 116 (via some error handling/recover process), 
database entries in appropriate data repositories are up- 
dated in this example at block 118. In example embodi- 
ments, once confirmations for an account-holder's re- 
quests are received and logged, the data repository can 
generate an information output to a confirmation produc- 
tion system or customer fulfillment system, at block 120. 
The fulfillment system in this case produces a confirma- 
tion to be sent to the account holder at block 122. This 
confirmation may take many forms, such as, but not lim- 
ited to, Email, postal mail or even a telephone call made 
either manually or by an automated telephone dialing sys- 
tem. The form of confirmation can be tailored to each ac- 
count-holder customer based on stated preferences. 



[0021] FIG. 2 illustrates one, specific example system software 
architecture that can be used to implement an example 
embodiment of the invention. FIG. 2 is broken into FIG. 2A 
and 2B for clarity. It cannot be over-emphasized that the 
architecture of FIG. 2 is an example only. Indeed, there are 
infinite possibilities as to how a system that implements 
embodiments of the invention can be designed. Front-end 
interface(s) 202 receive third-party transactions requests 
and manage communication with account holders, finan- 
cial institution employees, etc. The communications may 
be with individual customers, businesses, financial insti- 
tution branch employees who are assisting customers, etc. 
These entities are represented by communication termi- 
nals 204, which may be personal computers, servers, and 
the like. Front-end data 206 that is received via interface 
202 is first processed by the common Ul (user interface) 
engine, 208. The common Ul engine can provide a Web 
browser based user interface that will display the appro- 
priate Web pages to gather the data necessary to set up 
accounts with biller and direct depositor participants in 
order to support the recurring payments and direct de- 
posits. This interface may be interactive, in that it can 
provide for viewing customer profiles and status informa- 



tion. It may also provide feedback to verify that the data is 
entered correctly. 
[0022] Account-holder profile engine 210 communicates with 

various databases within the data repositories that are in- 
volved in implementing an embodiment of the invention. 
Engine 210 also manages customer/account authentica- 
tion process 212. The customer/account authentication 
process verifies that the account holder is who they say 
they are and that they have the authority to authorize 
third-party transactions. In the case where a financial in- 
stitution employee is assisting an account-holder cus- 
tomer, this could be done, at least in part, manually. Ac- 
count-holder profile engine 210 also matches a partici- 
pant with an account-holder's account and the request in 
order to authorize a recurring payment or direct deposit 
against that account. The account-holder profile engine 
can also provide for modifying third-party transactions 
and participants, such as replacing one with another, or 
deleting a participant and any corresponding transactions. 
Account-holder profile engine 210, in this example, also 
maintains the status of the relationship between accounts 
and participants, and records information on transaction 
requests. 



[0023] Workflow processing engine 214 of FIG. 2 manages the 
flow of data, including results, between the various com- 
munication engines, and common Ul engine 208. In some 
embodiments, workflow processing engine 214 can at- 
tempt to correct any errors through reiterative transmis- 
sions with biller communication engine 220 and direct 
depositor communication engine 226 prior to sending re- 
sults to account-holder confirmation engine 216. Ac- 
count-holder confirmation engine 216, using the financial 
systems data 244, in at least some embodiments, deter- 
mines the method and time of day for communicating to 
the account holder. As previously discussed, this commu- 
nication can take a form according to the account- 
holder's preferences. In this example embodiment, this 
communication takes place via the interface, 217, to a 
customer fulfillment system, which generates confirma- 
tion communications to account holders. 

[0024] BM| er participant profile engine 218, in example embodi- 
ments, adds new biller participants to the system, deletes 
existing biller participants from the system, and changes 
stored information about biller participants. It can also be 
designed to handle queries and return lists of biller par- 
ticipants, for example, by business type or zip code. Biller 



communications engine 220, in this example, sorts daily 
biller requests by biller participant, generates instructions 
for each account holder to acquire the proper information 
for a participant as part of a transaction request, then 
sends requests to the biller's systems. These requests are 
sent through participant interface 222. The format can be 
according to individual biller communication preferences 
that can be specified in a biller's participant profile as will 
be discussed in more detail later. 
[0025] The direct depositor participant profile engine, 224, in 
this embodiment adds new direct depositor participants 
to the system, deletes existing direct depositor partici- 
pants from the system, and changes stored information 
about direct depositor participants. It can also be de- 
signed to handle queries and return lists of direct deposi- 
tor participants, for example, by business type or zip 
code. Direct depositor communications engine 226, in 
this example, sorts daily direct deposit requests by direct 
deposit participant, generates instructions for each ac- 
count holder to acquire the proper information for a par- 
ticipant as part of a transaction request, then sends re- 
quests to the direct depositor's systems. These requests 
are sent through participant interface 222. The system 



can be designed so that the format is according to indi- 
vidual direct depositor communication preferences that 
can be specified in a participant's profile. All of the finan- 
cial institution's systems, engines, data repositories, etc. 
can be subject to reporting, monitoring, and tracking for 
or by information technology and management personnel 
as is known in the art. 
[0026] a customer fulfillment system in example embodiments of 
the invention can include an Email generation system, 
228, and a letter generation system, 230, to provide con- 
firmations to account holders. Biller participant systems 
can include a biller request handler, 232. The biller re- 
quest handler can receive files from biller communications 
engine 220, and verify the successful receipt. For each 
transaction, the request handler can direct the setup of an 
auto-debit recurring transaction with the account-holder's 
specified account, direct changes to standing transac- 
tions, stop an auto-debit, or update account information 
as needed. The biller request handler can also generate a 
response as to the status of a change request and send 
the results back to the financial institution. A biller ac- 
count authentication process, 234, provides account au- 
thentication services within a biller's systems, for exam- 



pie, to verify that the financial institution's account holder 
is actually a customer of the biller. 

[0027] Direct depositor participant systems can include a direct 
depositor request handler, 236. The direct depositor re- 
quest handler can receive files from direct depositor com- 
munications engine 226, and verify the successful receipt. 
For each transaction, the request handler can direct the 
setup of a recurring direct deposit with the account- 
holder's specified account, direct changes to standing 
transactions, stop a recurring direct deposit, or update 
account information as needed. The direct depositor re- 
quest handler can also generate a response as to the sta- 
tus of a change request and send the results back to the 
financial institution. A direct depositor account authenti- 
cation process, 238, provides account authentication ser- 
vices within a direct depositor's systems, for example, to 
verify that the financial institution's account holder is ac- 
tually an employee or other proper recipient of funds from 
the direct depositor. 

[0028] | n example embodiments of the invention, a data reposi- 
tory or data repositories can be organized into individual 
databases or data stores as needed. In the example of FIG. 
2, account-holder profiles database 240 contains infor- 



mation about the request including the selected partici- 
pants, the selected accounts, status, the selected methods 
of payment, etc. for each account-holder customer of the 
financial institution. The account-holder event log, 242, 
contains a record of all the activity that has occurred 
against the account-holder profiles to support any ques- 
tions or issues that may arise. Financial systems database, 
244, contains the demographic information about the ac- 
count holder which can be obtained from the account- 
holder's customer records. 
[0029] Biller profiles database 246 contains information about 
biller participants. This information can include name, 
type of company, zip code, and communication prefer- 
ences, content data for transaction requests and returned 
responses, and similar information. Biller event log 248 
contains a record of the activity that has occurred against 
the biller profiles to support any questions or issues that 
may arise. The daily biller requests database, 250, con- 
tains the requests that have been generated for process- 
ing by the various biller participants. If the system is set 
up for batch processing, these may be accumulated 
throughout the day in preparation for overnight file trans- 
missions to those participants. 



[0030] Direct depositor profiles database 252 contains informa- 
tion about direct depositor participants. This information 
can include name, type of company, zip code, and com- 
munication preferences, content data for transaction re- 
quests and returned responses, and similar information. 
Direct depositor event log 254 contains a record of the 
activity that has occurred against the direct depositor pro- 
files to support any questions or issues that may arise. 
The daily direct depositor requests database, 256, con- 
tains the requests that have been generated for process- 
ing by the various direct depositor participants. If the sys- 
tem is set up for batch processing, these may be accumu- 
lated throughout the day in preparation for overnight file 
transmissions to those participants. Again, the organiza- 
tion, architecture, and content of the data repositories 
discussed herein represents only an example of how data 
repositories supporting an embodiment of the invention 
can be set up. 

[0031] As discussed above, the appropriate data repositories in 
embodiments of the invention can contain third-party 
(biller or direct depositor) information. This information 
can be stored in the form of a participant profile, which 
can provide considerable flexibility in the way the financial 



institution deals with third-party participants. FIG. 3 is a 
schematic representation of an example participant pro- 
file, 300. The profile in this example can include partici- 
pant identification and demographic information 302, 
which can include a company identifier, a company name, 
address, and telephone numbers, primary and support 
contact information, and a list of zip codes or other types 
of geographies serviced by the company. Content data 
304 can include formatting information regarding both 
account-holder requests and participant responses. Such 
data can include, but is not limited to, a list of required 
data elements, a list of optional data elements and format 
information. Format information can include, for example, 
delimiters, and/or (extensible markup language (XML) 
document formats with field labels, etc. With respect to 
participant confirmation responses, the content data can 
also include a list of response codes, and data elements 
associated with each response code. 
[0032] Communication preferences 306 of FIG. 3 can be included 
to specify methods of communication and communication 
paths to be used with the participant. These methods can 
include batch files sent via the Internet or possibly some 
other from of electronic communication, Emails with at- 



tachments, via a Web site, etc. Disclosure information 308 
is where legal disclosure which might be required by a 
participant can be stored for presentation to an account 
holder at the appropriate time, which may be at the time 
third-party transaction requests are collected from the 
account holder. Finally, scripts 310 can be provided to aid 
in gathering appropriate information from account hold- 
ers. 

[0033] As previously discussed, the use of stored profiles can al- 
low the communication processes between a financial in- 
stitution, participants, and account holders to be tailored 
to the preferences of individual parties, assuming appro- 
priate hardware and software systems are in place. Re- 
quest information can be written in XML format within a 
customer request repository for processing in real time or 
at the end of a business day in batch fashion. A partici- 
pant's preferences in a participant profile can specify 
message transport, such as over HTTPS, TCP/IP with a URL 
address, IBM System Network Architecture (SNA) over a 
dedicated connection, SOAP (simple object access proto- 
col)/HTTPS over TCP/IP with a URL address, etc. 

[0034] R ea | t j me processing for sending transaction requests to 
participants can be accomplished, for example, by Web- 



site access or real-time messaging. In the case of Website 
access, XML data can be parsed and merged into a script 
from the participant profile. The script can then be exe- 
cuted. If the script executes successfully, the result can be 
recorded in the appropriate event log, creating a record in 
a "processing completed in real-time" file. The record can 
then be deleted from a "process pending in real-time" file. 
If the script fails, a specified number of retries can be at- 
tempted. If the script still fails, this result can be recorded 
in the event log, creating a record in a "processing failed 
in real-time" file for error handling, as previously dis- 
cussed, which may include manual processing. The record 
can then be deleted from a "process pending in real-time" 
file. 

[0035] if the type of communication is "real-time messaging" and 
XML is used, XML data is parsed and put into the message 
format specified in the participant profile. 

[0036] The message can be sent according to the participant's 
communication preferences. If a confirmation is received 
from the participant that the message was received and 
processed successfully, the result can be recorded in the 
appropriate event log, creating a record in a "processing 
completed in real-time" file, and then deleting the record 



from a "process pending in real-time" file. If a participant 
communicates that the message was received but failed to 
be processed, that result can be recorded in the event log, 
creating a record in a "processing failed in real-time" file 
for error handling and then deleting the record from a 
"process pending in real-time" file. 

[0037] |f no confirmation is received from a third-party partici- 
pant, retries can be attempted. If no confirmation is forth- 
coming, this result can again be recorded in the appropri- 
ate event log for error handling (and deleted from a pend- 
ing file) as before. 

[0038] As an example of batch processing of requests, such re- 
quests can be handled at the end of the business day. The 
requests can be stored in a list in a "to be processed at 
end of day" file and sorted by a participant identifier so 
that all account-holder requests throughout the data for a 
given third-party participant will be together for process- 
ing. This list can be read, and saved as a record in a "pro- 
cess pending at end of day" file. Again, if XML is used to 
format this list, the XML data is parsed and put in a record 
format specified in the participant's profile. That record 
can then be written to a file. A copy of the file can be sent 
to a participant according to the participant's communica- 



tion preferences. If a confirmation is received that indi- 
cates the file was received and processed successfully, the 
result is recorded in an appropriate event log, creating a 
record in a "process completed at end of day" file. If there 
are indications of a failure, a record can be created in a 
"processing failed at end of day" file, in a fashion similar 
to that described above with reference to real-time pro- 
cessing. Likewise, retries can be attempted if no confir- 
mation is received from a participant. For paper or Email 
transmission of all customer requests for a given partici- 
pant, the process can be similar. In such a case, XML data 
can be merged with a form template to create a report 
with all the account-holder requests for the participant 
that can be printed or attached to an Email. 
[0039] FIG. 4 provides a network diagram showing network con- 
nections and hardware platforms that can be used to im- 
plement example embodiments of the invention. FIG. 4 is 
broken into FIG. 4A and 4B for clarity. Again, it cannot be 
overemphasized that FIG. 4 provides an illustrative exam- 
ple only, as many different network configurations can be 
architected by one of skill in the art. In the example sys- 
tem of FIG. 4, at least some aspects of the common user 
interface are provided by Web server 402. Computing 



platform 404, in this example, a server, provides sorting, 
parsing, and routing functions, and implements at least 
some of the software engines, for example, the profile 
engines, the workflow processing engine, the biller com- 
munication engine, and the direct depositor communica- 
tion engine. Computing platform 404 communicates with 
data repositories 406 and financial systems 408, wherein 
financial systems data and the account-holder authentica- 
tion process reside. Fulfillment system 410 produces ac- 
count-holder confirmations via either a mail processing 
facility, 412, or an Email system, 414, as previously dis- 
cussed. Computing facilities (not shown) within the fulfill- 
ment system also maintain the account-holder confirma- 
tion engine. Because many of its functions relate to sort- 
ing and routing transaction requests, computing platform 
404 may be referred to herein as a sorter/router. 
[0040] Financial institution branch terminal 416 and terminals at 
the financial institution's call center, 418, can be used to 
input third-party transaction authorization requests on 
behalf of account-holder customers. These terminals can 
be implemented by standard computing platforms and 
connected to the common user interface via the Internet 
or a corporate intranet, 420. In the case of an Internet 



connection, firewall 422 and the normal access and rout- 
ing arrangements, 424, can be included in the system, as 
is well-understood in the art. These components can be 
viewed as forming a front-end interface or front-end in- 
frastructure, 425. In a case where connectivity is provided 
by a corporate intranet, the corporate intranet may also be 
considered part of the front-end interface. Also in the 
case of an Internet connection, it is possible to allow ac- 
count-holder customers of the financial institution to ac- 
cess the system directly via secure Web site or dedicated 
application, as from their own personal computers, 426 
and 428. These various access devices can receive ac- 
count specific information from financial systems element 
408, which provides existing account and financial insti- 
tution relationship data. The functionality available to 
users via any of these access methods can be determined 
by the user's level of authorization and may be cus- 
tomized in accordance with the needs of the user and/or 
their access element, as is well-understood in the art. 
Transmissions between the above-discussed hardware el- 
ements may be supported by Web, hardwired analog/digi- 
tal communication links, wireless analog/digital commu- 
nications links, any combination thereof, or other means 



for communicating. 

[0041] when sorter/router 404 receives transaction request data, 
which can include financial, personal, and depositor/biller 
specific data elements) and transaction requests from user 
interface 402, it logs the receipt of the data within data 
repositories 406. Sorter/router 404 sorts and transmits 
the information to the third-party participant interface, 
430. This transmission may be supported by Web, hard- 
wired analog/digital communication links, wireless ana- 
log/digital communications links, fax, paper, any combi- 
nation thereof, or other means for establishing and oper- 
ating communications links. As an illustrative example, 
paper handling facilities 432, and a network server, 434 
are illustrated in FIG. 4. Participant systems, 440, receive 
the transaction request data. 

[0042] | n the case of electronic transmission, network 442 inter- 
connects the third-party participant interface with partici- 
pant systems 440. The Internet can be used, in which 
case, firewall(s) and access and routing hardware would 
exist as previously discussed, but these are not shown in 
FIG. 4 for clarity. Other forms of electronic communication 
may also be used to provide this network facility. Note 
that if participants have interactive access to the financial 



institution's systems, the interactive communications can 
be routed through the same Internet connection, and 
would typically also be managed by a network server, like 
network server 434. When transaction requests are sent to 
third-party participants, sorter/router 404 can log the 
transmission of information within data repositories 406. 
[0043] The participant systems, 440, can process the information 
received in the transmission via links. Any single partici- 
pant may have multiple types of accounts and have multi- 
ple relationships with customers of the financial institu- 
tion, and may have internal links to an accounts receivable 
system, 449, for debits, and an accounts payable system, 
450, and/or a payroll system, 451, both for direct de- 
posits. These systems update to reflect the directive(s) re- 
ceived, and transmit back to the participant interface, 
430, a confirmation of whether the processing of each re- 
quest was successful and, if so, an applicable date for the 
request to become effective. Proxy dates using a logical 
sequencing methodology may also be used and can be 
assigned by either participant interface 430, or the appro- 
priate participant system, and to the accounts receivable 
system 449, the accounts payable system 450, or the 
payroll system 451. Proxy dates can also be assigned by 



sorter/router 404. The entity and manor in which dates 
are assigned can be set according to a participant's pref- 
erence. 

[0044] Participant interface 430 transmits the confirmation and 
applicable date for a request to become effective back to 
sorter/router 404. This transmission can be accomplished 
with the same communications link used to send the re- 
quest from the sorter/router to the interface. Sorter/ 
router 404 logs the received confirmation within data 
repositories 406. In at least some embodiments, upon re- 
ceiving confirmations to all outstanding transaction re- 
quests, the sorter/router creates a transmission to fulfill- 
ment system 410. This transmission may be supported by 
Web, hardwired analog/digital communication links, wire- 
less analog/digital communications links, fax, paper, any 
combination thereof, or other means for establishing and 
operating communications links. 

[0045] As previously discussed, in example embodiments, fulfill- 
ment system 410 receives the transmission from the data 
repositories and creates, queues and produces a confir- 
mation for the account holder impacted by the requested 
changes. The account-holder confirmation may be deliv- 
ered via Web, Email, hardwired analog/digital communi- 



cation links, wireless analog/digital communications links, 
fax, paper, postal service, courier service, telegram, voice 
response unit (VRU), telephone call, any combination 
thereof, or other means preferable to the account holder 
for communicating a confirmation of activity. Creation and 
delivery of the confirmation can also be logged within 
data repositories 406. 

[0046] user interface 402, as previously discussed, can be acces- 
sible in some embodiments via the branch terminal 416 of 
the financial institution, via terminals within call center 
418, or via remote terminals or personal computers, 426 
and 428. In some embodiments, any and all of these ac- 
cess points can be used to review all elements of the sta- 
tus of the process throughout the processing of a request 
and afterward via a status transaction interface that can 
interact with sorter/router 404. In such a case, sorter/ 
router 404 queries databases within data repositories 406 
for the needed information then transmits appropriate re- 
sponses back through user interface 402 for display. The 
system can also be set up so that a user of any of these 
terminals can log free-form queries that will be output 
from sorter/router 404 for research activities. 

[0047] a computer program which implements all or parts of the 



invention through the use of systems like those illustrated 
in FIG. 4 can take the form of a computer program prod- 
uct residing on a computer usable or computer readable 
storage medium. One example of such a medium is a re- 
movable storage cartridge, as shown at 460 in FIG. 4. 
Such a cartridge might store computer program instruc- 
tions optically, such as in the case of a DVD-RAM car- 
tridge, or magnetically, such as in the case of a high- 
capacity diskette type device such as a so-called "ZIP" 
disk. A computer program product containing the pro- 
gram of instructions can be supplied in such a form, and 
loaded on the machines involved, either directly, or over a 
network. Such computer program instructions, also com- 
monly referred to as "software" directs the operation of 
computing platforms or instruction execution platforms to 
carry out processes of embodiments of the invention. The 
"medium" can also be simply a stream of information be- 
ing retrieved when the computer program product is 
"downloaded" through the Internet or an intranet. Com- 
puter programs can reside on any medium that can con- 
tain, store, communicate, propagate, or transport the pro- 
gram for use by or in connection with an instruction exe- 
cution system, apparatus, or device. The computer usable 



or computer readable medium may be, for example, but 
not limited to, an electronic, magnetic, optical, electro- 
magnetic, infrared or semiconductor system, or a propa- 
gation medium. Note that the computer usable or com- 
puter readable medium can even be paper or another 
suitable medium on which the program instructions are 
printed. In this case, the program could be electronically 
captured via optical scanning of the paper or other 
medium, then processed in a suitable manner. 
[0048] specific embodiments of an invention are described 

herein. One of ordinary skill in the computing and finan- 
cial services arts will quickly recognize that the invention 
has other applications in other environments. In fact, 
many embodiments and implementations are possible. 
The following claims are in no way intended to limit the 
scope of the invention to specific embodiments described 
above. 



